<?php
/**
 * <https://y.st./>
 * Copyright © 2016 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'title' => 'Coding standards',
	'body' => <<<END
<img src="/img/CC_BY-SA_4.0/y.st./weblog/2016/11/07.jpg" alt="White flowers and pink buds" class="weblog-header-image" width="811" height="480" />
<p>
	Current countdowns:
</p>
<ul>
	<li>234 scheme-specific $a[URI]-parsing classes to write and add to <a href="https://git.vola7ileiax4ueow.onion/y.st./include.d/releases">include.d</a></li>
	<li>1 free elective left in my associate degree program</li>
	<li>4 free electives left in my bachelor degree program</li>
</ul>
<p>
	Topics for essays that I want to write outside of school:
</p>
<ul>
<li>How the $a[GFDL] isn&apos;t a free license, and is effectively nonfree even when invariant sections aren&apos;t used</li>
<li>How the telephone number system is screwy</li>
<li>How postpaid mobile plans are bad for customers</li>
<li>How connections using &quot;untrusted&quot; $a[TLS] certificates are more trustworthy than connections without any $a[TLS] certificate at all</li>
<li>The importance of free software</li>
<li>The importance of free media</li>
</ul>
<p>
	I spoke with the author of that article on <a href="https://ocramius.github.io./blog/accessing-private-php-class-members-without-reflection/">bypassing the <code>private</code> key word in $a[PHP]</a>, and it seems that while they approve of this ability to render the <code>private</code> key word ineffective, they only approve of doing this from within libraries and tools.
	They don&apos;t think that it should be used from the main code of a project.
	I don&apos;t think that closures belong in libraries and tools though, but in the main project.
	From within a library, regular, named functions and methods should be used.
	The only place that I&apos;d ever use closures is in non-library code.
	After all, closures are class instances, which makes them variables, not functions.
	With that in mind, our opinions on the usage of closures is incompatible.
	However, it doesn&apos;t detract from the real issue.
	When developers mark a property (or method) as private, they do so for a reason.
	The author said that the code used for object serialization shouldn&apos;t be contained within the class definition itself, but in my opinion, it should.
	Serialization is a feature of the objects of a class, so it should be defined by the class itself.
	If it&apos;s necessary to define it separately and not have it as part of the object (so using a parent class with the serialization code isn&apos;t an option because the code would become a part of the object&apos;s definition when the child class inherits it), make the properties protected instead of private.
	Then, have a serializer class extend the class that has the data objects and use static methods in the child class to interact with the protected properties of the parent class.
</p>
<p>
	I finished up my work on the function for finding what parts of include.d to include in a project if trying to avoid dependencies, and have made a new <a href="https://git.vola7ileiax4ueow.onion/y.st./include.d/releases">release</a>.
	Though the point of this release is the new function, I&apos;ve also included my fixes to the main $a[URI]-handling framework.
	I wanted to wait and release those fixes with the rest of the big $a[URI] scheme update, but my debug code makes assumptions that aren&apos;t valid for outdated versions of include.d code from before the 0.0.1.4 release.
	Specifically, the debugging code complains about repeated exception codes where the exception codes actually are unique.
	As the $a[URI]-handling code is being worked on only in another branch, the version in the master branch had stagnated, so the assumptions about how to find the exception codes didn&apos;t apply, confusing the debugging code.
	I don&apos;t anticipate further issues with the branched $a[URI]-handling code though.
	I&apos;ve also removed a couple of exception classes that, had I read the description of their parent classes correctly, I would never have included in include.d anyway.
</p>
<p>
	I spent a chunk of the day looking for boxes of things that can be stashed in the storage unit, but it&apos;s not my stuff so I have no idea what needs to be kept accessible and what can be stored for the time being.
	Needless to say, it didn&apos;t go well.
	I also labeled the boxes on the high shelves in the garage though, which should be of some use.
</p>
<p>
	My <a href="/a/canary.txt">canary</a> still sings the tune of freedom and transparency.
</p>
END
);
